JavaScript ಅಸಿಂಕ್ ಸಂದರ್ಭ ಮತ್ತು ಥ್ರೆಡ್ ಸುರಕ್ಷತೆ: ಸಂದರ್ಭ ಪ್ರತ್ಯೇಕತೆ ನಿರ್ವಹಣೆಯ ಆಳವಾದ ವಿಶ್ಲೇಷಣೆ

ಆಧುನಿಕ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ಜಗತ್ತಿನಲ್ಲಿ, ವಿಶೇಷವಾಗಿ ಸರ್ವರ್-ಸೈಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ, ಸ್ಟೇಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು ಒಂದು ಮೂಲಭೂತ ಸವಾಲಾಗಿದೆ. ಬಹು-ಥ್ರೆಡೆಡ್ ವಿನಂತಿ ಮಾದರಿಯನ್ನು ಹೊಂದಿರುವ ಭಾಷೆಗಳಿಗೆ, ಥ್ರೆಡ್-ಲೋಕಲ್ ಸ್ಟೋರೇಜ್ ಪ್ರತಿ-ಥ್ರೆಡ್, ಪ್ರತಿ-ವಿನಂತಿಯ ಆಧಾರದ ಮೇಲೆ ಡೇಟಾವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಸಾಮಾನ್ಯ ಪರಿಹಾರವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದರೆ Node.js ನಂತಹ ಸಿಂಗಲ್-ಥ್ರೆಡೆಡ್, ಈವೆಂಟ್-ಡ್ರಿವನ್ ಪರಿಸರದಲ್ಲಿ ಏನಾಗುತ್ತದೆ? ವಿನಂತಿಗೆ-ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭವನ್ನು—ವ್ಯವಹಾರ ID, ಬಳಕೆದಾರರ ಸೆಷನ್, ಅಥವಾ ಸ್ಥಳೀಕರಣ ಸೆಟ್ಟಿಂಗ್‌ಗಳಂತಹವು—ಇತರ ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳಿಗೆ ಸೋರಿಕೆಯಾಗದಂತೆ ಅಸಮಕಾಲಿಕ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಂಕೀರ್ಣ ಸರಣಿಯಾದ್ಯಂತ ನಾವು ಸುರಕ್ಷಿತವಾಗಿ ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೇವೆ?

ಇದು ಅಸಮಕಾಲಿಕ ಸಂದರ್ಭ ನಿರ್ವಹಣೆಯ ಪ್ರಮುಖ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಇದನ್ನು ಪರಿಹರಿಸಲು ವಿಫಲವಾದರೆ ಗೊಂದಲಮಯ ಕೋಡ್, ಬಿಗಿಯಾದ ಜೋಡಣೆ, ಮತ್ತು ಕೆಟ್ಟ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಒಬ್ಬ ಬಳಕೆದಾರರ ವಿನಂತಿಯಿಂದ ಬಂದ ಡೇಟಾ ಇನ್ನೊಬ್ಬರ ವಿನಂತಿಯನ್ನು ಕಲುಷಿತಗೊಳಿಸುವ ಭೀಕರ ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಇದು ಸಾಂಪ್ರದಾಯಿಕ ಥ್ರೆಡ್‌ಗಳಿಲ್ಲದ ಜಗತ್ತಿನಲ್ಲಿ 'ಥ್ರೆಡ್ ಸುರಕ್ಷತೆ'ಯನ್ನು ಸಾಧಿಸುವ ಪ್ರಶ್ನೆಯಾಗಿದೆ.

ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿಯು JavaScript ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಈ ಸಮಸ್ಯೆಯ ವಿಕಾಸವನ್ನು ಅನ್ವೇಷಿಸುತ್ತದೆ, ನೋವಿನ ಕೈಪಿಡಿ ಪರಿಹಾರಗಳಿಂದ Node.js ನಲ್ಲಿನ `AsyncLocalStorage` API ಒದಗಿಸಿದ ಆಧುನಿಕ, ದೃಢವಾದ ಪರಿಹಾರದವರೆಗೆ. ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಸ್ಕೇಲೆಬಲ್ ಮತ್ತು ಅವಲೋಕನೀಯ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಇದು ಏಕೆ ಅತ್ಯಗತ್ಯ, ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಅದನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಹೇಗೆ ಅಳವಡಿಸುವುದು ಎಂಬುದನ್ನು ನಾವು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ.

ಸವಾಲು: ಅಸಮಕಾಲಿಕ JavaScript ನಲ್ಲಿ ಕಣ್ಮರೆಯಾಗುವ ಸಂದರ್ಭ

ಪರಿಹಾರವನ್ನು ನಿಜವಾಗಿಯೂ ಪ್ರಶಂಸಿಸಲು, ನಾವು ಮೊದಲು ಸಮಸ್ಯೆಯನ್ನು ಆಳವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. JavaScript ನ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮಾದರಿಯು ಒಂದೇ ಥ್ರೆಡ್ ಮತ್ತು ಈವೆಂಟ್ ಲೂಪ್ ಅನ್ನು ಆಧರಿಸಿದೆ. ಅಸಮಕಾಲಿಕ ಕಾರ್ಯಾಚರಣೆಯನ್ನು (ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆ, HTTP ಕರೆ, ಅಥವಾ `setTimeout` ನಂತಹ) ಪ್ರಾರಂಭಿಸಿದಾಗ, ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಸಿಸ್ಟಮ್‌ಗೆ (OS ಕರ್ನಲ್ ಅಥವಾ ಥ್ರೆಡ್ ಪೂಲ್‌ನಂತಹ) ಕಳುಹಿಸಲಾಗುತ್ತದೆ. JavaScript ಥ್ರೆಡ್ ಇತರ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸ್ವತಂತ್ರವಾಗಿರುತ್ತದೆ. ಅಸಿಂಕ್ ಕಾರ್ಯಾಚರಣೆಯು ಪೂರ್ಣಗೊಂಡಾಗ, ಒಂದು ಕಾಲ್‌ಬ್ಯಾಕ್ ಕಾರ್ಯವನ್ನು ಕ್ಯೂನಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಕಾಲ್ ಸ್ಟಾಕ್ ಖಾಲಿಯಾದ ನಂತರ ಈವೆಂಟ್ ಲೂಪ್ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.

ಈ ಮಾದರಿಯು I/O-ಬೌಂಡ್ ಕಾರ್ಯಭಾರಗಳಿಗೆ ನಂಬಲಾಗದಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ, ಆದರೆ ಇದು ಗಮನಾರ್ಹ ಸವಾಲನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ: ಅಸಿಂಕ್ ಕಾರ್ಯಾಚರಣೆಯ ಪ್ರಾರಂಭ ಮತ್ತು ಅದರ ಕಾಲ್‌ಬ್ಯಾಕ್‌ನ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ನಡುವೆ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಂದರ್ಭವು ಕಳೆದುಹೋಗುತ್ತದೆ. ಕಾಲ್‌ಬ್ಯಾಕ್ ಈವೆಂಟ್ ಲೂಪ್‌ನ ಹೊಸ ಸರದಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅದನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಕಾಲ್ ಸ್ಟಾಕ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಗೊಳ್ಳುತ್ತದೆ.

ಸಾಮಾನ್ಯ ವೆಬ್ ಸರ್ವರ್ ಸನ್ನಿವೇಶದೊಂದಿಗೆ ವಿವರಿಸೋಣ. ವಿನಂತಿಯ ಜೀವಿತಾವಧಿಯಲ್ಲಿ ನಿರ್ವಹಿಸಲಾದ ಪ್ರತಿ ಕ್ರಿಯೆಯೊಂದಿಗೆ ಅನನ್ಯ `requestID` ಅನ್ನು ಲಾಗ್ ಮಾಡಲು ನಾವು ಬಯಸುತ್ತೇವೆ ಎಂದು ಊಹಿಸಿ.

ಸರಳ ವಿಧಾನ (ಮತ್ತು ಅದು ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ)

Node.js ಗೆ ಹೊಸಬರಾದ ಡೆವಲಪರ್ ಜಾಗತಿಕ ವೇರಿಯೇಬಲ್ ಬಳಸಲು ಪ್ರಯತ್ನಿಸಬಹುದು:

            
let globalRequestID = null;

// A simulated database call
function getUserFromDB(userId) {
  console.log(`[${globalRequestID}] Fetching user ${userId}`);
  return new Promise(resolve => setTimeout(() => resolve({ id: userId, name: 'Jane Doe' }), 100));
}

// A simulated external service call
async function getPermissions(user) {
  console.log(`[${globalRequestID}] Getting permissions for ${user.name}`);
  await new Promise(resolve => setTimeout(resolve, 150));
  console.log(`[${globalRequestID}] Permissions retrieved`);
  return { canEdit: true };
}

// Our main request handler logic
async function handleRequest(requestID) {
  globalRequestID = requestID;
  console.log(`[${globalRequestID}] Starting request processing`);
  const user = await getUserFromDB(123);
  const permissions = await getPermissions(user);
  console.log(`[${globalRequestID}] Request finished successfully`);
}

// Simulate two concurrent requests arriving at nearly the same time
console.log("Simulating concurrent requests...");
handleRequest('req-A');
handleRequest('req-B');

            

              
                Copy
              
            
          

ನೀವು ಈ ಕೋಡ್ ಅನ್ನು ಚಲಾಯಿಸಿದರೆ, ಔಟ್ಪುಟ್ ಕಲುಷಿತ ಗೊಂದಲವಾಗಿರುತ್ತದೆ:

            
Simulating concurrent requests...
[req-A] Starting request processing
[req-A] Fetching user 123
[req-B] Starting request processing
[req-B] Fetching user 123
[req-B] Getting permissions for Jane Doe
[req-B] Getting permissions for Jane Doe
[req-B] Permissions retrieved
[req-B] Request finished successfully
[req-B] Permissions retrieved
[req-B] Request finished successfully

            

              
                Copy
              
            
          

`req-B` ತಕ್ಷಣವೇ `globalRequestID` ಅನ್ನು ಹೇಗೆ ತಿದ್ದಿ ಬರೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. `req-A` ಗಾಗಿ ಅಸಿಂಕ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಪುನರಾರಂಭಗೊಳ್ಳುವ ಹೊತ್ತಿಗೆ, ಜಾಗತಿಕ ವೇರಿಯೇಬಲ್ ಬದಲಾಗಿದೆ, ಮತ್ತು ಎಲ್ಲಾ ನಂತರದ ಲಾಗ್‌ಗಳು ತಪ್ಪಾಗಿ `req-B` ಎಂದು ಟ್ಯಾಗ್ ಆಗುತ್ತವೆ. ಇದು ಕ್ಲಾಸಿಕ್ ರೇಸ್ ಕಂಡಿಷನ್ ಮತ್ತು ಏಕಕಾಲಿಕ ಪರಿಸರದಲ್ಲಿ ಜಾಗತಿಕ ಸ್ಥಿತಿಯು ಏಕೆ ದುರಂತಕಾರಿ ಎಂಬುದಕ್ಕೆ ಪರಿಪೂರ್ಣ ಉದಾಹರಣೆಯಾಗಿದೆ.

ನೋವಿನ ಕೆಲಸದ ಪರಿಹಾರ: ಪ್ರೊಪ್ ಡ್ರಿಲ್ಲಿಂಗ್

ಅತ್ಯಂತ ನೇರ, ಮತ್ತು ವಾದಯೋಗ್ಯವಾಗಿ ಅತ್ಯಂತ ತೊಡಕಿನ ಪರಿಹಾರವೆಂದರೆ ಕಾಲ್ ಚೈನ್‌ನಲ್ಲಿನ ಪ್ರತಿ ಕಾರ್ಯದ ಮೂಲಕ ಸಂದರ್ಭ ವಸ್ತುವನ್ನು ರವಾನಿಸುವುದು. ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ "ಪ್ರೊಪ್ ಡ್ರಿಲ್ಲಿಂಗ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

            
// context is now an explicit parameter
function getUserFromDB(userId, context) {
  console.log(`[${context.requestID}] Fetching user ${userId}`);
  // ...
}

async function getPermissions(user, context) {
  console.log(`[${context.requestID}] Getting permissions for ${user.name}`);
  // ...
}

async function handleRequest(requestID) {
  const context = { requestID };
  console.log(`[${context.requestID}] Starting request processing`);
  const user = await getUserFromDB(123, context);
  const permissions = await getPermissions(user, context);
  console.log(`[${context.requestID}] Request finished successfully`);
}

            

              
                Copy
              
            
          

ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಸುರಕ್ಷಿತ ಮತ್ತು ಊಹಿಸಬಹುದಾದದು. ಆದಾಗ್ಯೂ, ಇದು ಪ್ರಮುಖ ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ:

• ಬಾಯ್ಲರ್‌ಪ್ಲೇಟ್: ಪ್ರತಿ ಕಾರ್ಯದ ಸಿಗ್ನೇಚರ್, ಉನ್ನತ ಮಟ್ಟದ ನಿಯಂತ್ರಕದಿಂದ ಕಡಿಮೆ ಮಟ್ಟದ ಯುಟಿಲಿಟಿವರೆಗೆ, `context` ವಸ್ತುವನ್ನು ಸ್ವೀಕರಿಸಲು ಮತ್ತು ರವಾನಿಸಲು ಮಾರ್ಪಡಿಸಬೇಕು.
• ಬಿಗಿಯಾದ ಜೋಡಣೆ: ಸಂದರ್ಭದ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರ್ಯಗಳು ಸ್ವತಃ ಕಾಲ್ ಚೈನ್‌ನ ಭಾಗವಾಗಿರುವುದರಿಂದ ಅದರ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ. ಇದು ಶುದ್ಧ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಕಾಳಜಿಗಳ ಪ್ರತ್ಯೇಕತೆಯ ತತ್ವಗಳನ್ನು ಉಲ್ಲಂಘಿಸುತ್ತದೆ.
• ದೋಷ-ಪ್ರವೃತ್ತಿ: ಡೆವಲಪರ್ ಒಂದು ಹಂತದ ಕೆಳಗೆ ಸಂದರ್ಭವನ್ನು ರವಾನಿಸಲು ಮರೆಯುವುದು ಸುಲಭ, ಇದು ಎಲ್ಲಾ ನಂತರದ ಕರೆಗಳಿಗೆ ಚೈನ್ ಅನ್ನು ಮುರಿಯುತ್ತದೆ.

ವರ್ಷಗಳಿಂದ, Node.js ಸಮುದಾಯವು ಈ ಸಮಸ್ಯೆಯೊಂದಿಗೆ ಹೋರಾಡಿತು, ಇದು ವಿವಿಧ ಗ್ರಂಥಾಲಯ-ಆಧಾರಿತ ಪರಿಹಾರಗಳಿಗೆ ಕಾರಣವಾಯಿತು.

ಪೂರ್ವವರ್ತಿಗಳು ಮತ್ತು ಆರಂಭಿಕ ಪ್ರಯತ್ನಗಳು: ಆಧುನಿಕ ಸಂದರ್ಭ ನಿರ್ವಹಣೆಯ ಹಾದಿ

ಅನಗತ್ಯಗೊಂಡ `domain` ಮಾಡ್ಯೂಲ್

Node.js ನ ಆರಂಭಿಕ ಆವೃತ್ತಿಗಳು ದೋಷಗಳನ್ನು ನಿಭಾಯಿಸಲು ಮತ್ತು I/O ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಗುಂಪು ಮಾಡಲು `domain` ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಪರಿಚಯಿಸಿದವು. ಇದು ಅಸಮಕಾಲಿಕ ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಳನ್ನು ಸಕ್ರಿಯ "ಡೊಮೇನ್" ಗೆ ಅಸ್ಪಷ್ಟವಾಗಿ ಬಂಧಿಸಿತು, ಇದು ಸಂದರ್ಭ ಡೇಟಾವನ್ನು ಸಹ ಹೊಂದಿರಬಹುದು. ಇದು ಭರವಸೆ ನೀಡುತ್ತಿದ್ದರೂ, ಇದು ಗಮನಾರ್ಹ ಕಾರ್ಯಕ್ಷಮತೆಯ ಓವರ್ಹೆಡ್ ಅನ್ನು ಹೊಂದಿತ್ತು ಮತ್ತು ಕುಖ್ಯಾತವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ, ಸಂದರ್ಭವು ಕಳೆದುಹೋಗುವ ಸೂಕ್ಷ್ಮ ಅಂಚಿನ ಪ್ರಕರಣಗಳೊಂದಿಗೆ. ಇದನ್ನು ಅಂತಿಮವಾಗಿ ಅನಗತ್ಯಗೊಳಿಸಲಾಯಿತು ಮತ್ತು ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಬಳಸಬಾರದು.

ಕಂಟಿನ್ಯುಯೇಷನ್-ಲೋಕಲ್ ಸ್ಟೋರೇಜ್ (CLS) ಗ್ರಂಥಾಲಯಗಳು

ಸಮುದಾಯವು "ಕಂಟಿನ್ಯುಯೇಷನ್-ಲೋಕಲ್ ಸ್ಟೋರೇಜ್" ಎಂಬ ಪರಿಕಲ್ಪನೆಯೊಂದಿಗೆ ಮುಂದೆ ಬಂದಿತು. `cls-hooked` ನಂತಹ ಗ್ರಂಥಾಲಯಗಳು ಬಹಳ ಜನಪ್ರಿಯವಾದವು. ಅವು Node ಯ ಆಂತರಿಕ `async_hooks` API ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕಾರ್ಯನಿರ್ವಹಿಸಿದವು, ಇದು ಅಸಮಕಾಲಿಕ ಸಂಪನ್ಮೂಲಗಳ ಜೀವಿತಾವಧಿಯ ಬಗ್ಗೆ ಗೋಚರತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಈ ಗ್ರಂಥಾಲಯಗಳು ಮೂಲತಃ Node.js ನ ಅಸಿಂಕ್ ಪ್ರಿಮಿಟಿವ್‌ಗಳನ್ನು ಪ್ಯಾಚ್ ಮಾಡ ಅಥವಾ "ಮಂಕಿ-ಪ್ಯಾಚ್" ಮಾಡ, ಪ್ರಸ್ತುತ ಸಂದರ್ಭವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು. ಅಸಿಂಕ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಗ್ರಂಥಾಲಯವು ಪ್ರಸ್ತುತ ಸಂದರ್ಭವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಅದರ ಕಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಚಲಾಯಿಸಲು ನಿಗದಿಪಡಿಸಿದಾಗ, ಗ್ರಂಥಾಲಯವು ಕಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು ಆ ಸಂದರ್ಭವನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ.

`cls-hooked` ಮತ್ತು ಇದೇ ರೀತಿಯ ಗ್ರಂಥಾಲಯಗಳು ಪ್ರಮುಖವಾಗಿದ್ದರೂ, ಅವು ಇನ್ನೂ ಒಂದು ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರವಾಗಿದ್ದವು. ಅವು ಬದಲಾಗಬಹುದಾದ ಆಂತರಿಕ API ಗಳನ್ನು ಅವಲಂಬಿಸಿವೆ, ಅವು ತಮ್ಮದೇ ಆದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿರಬಹುದು, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ `async/await` ನಂತಹ ಹೊಸ JavaScript ಭಾಷಾ ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ ಸಂದರ್ಭವನ್ನು ಸರಿಯಾಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಹೋರಾಡಿದವು, ಪರಿಪೂರ್ಣವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡದಿದ್ದರೆ.

ಆಧುನಿಕ ಪರಿಹಾರ: `AsyncLocalStorage` ಅನ್ನು ಪರಿಚಯಿಸುವುದು

ಸ್ಥಿರ, ಪ್ರಮುಖ ಪರಿಹಾರದ ನಿರ್ಣಾಯಕ ಅಗತ್ಯವನ್ನು ಗುರುತಿಸಿ, Node.js ತಂಡವು `AsyncLocalStorage` API ಅನ್ನು ಪರಿಚಯಿಸಿತು. ಇದು Node.js v14 ರಲ್ಲಿ ಸ್ಥಿರವಾಯಿತು ಮತ್ತು ಇಂದು ಅಸಮಕಾಲಿಕ ಸಂದರ್ಭವನ್ನು ನಿರ್ವಹಿಸಲು ಪ್ರಮಾಣಿತ, ಶಿಫಾರಸು ಮಾಡಿದ ವಿಧಾನವಾಗಿದೆ. ಇದು ಹುಡ್ ಅಡಿಯಲ್ಲಿ ಅದೇ ಶಕ್ತಿಶಾಲಿ `async_hooks` ಯಾಂತ್ರಿಕತೆಯನ್ನು ಬಳಸುತ್ತದೆ ಆದರೆ ಶುದ್ಧ, ವಿಶ್ವಾಸಾರ್ಹ, ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಾರ್ವಜನಿಕ API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.

`AsyncLocalStorage` ನಿಮಗೆ ಅಸಮಕಾಲಿಕ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಂಪೂರ್ಣ ಸರಣಿಯಾದ್ಯಂತ ಉಳಿಯುವ ಪ್ರತ್ಯೇಕ ಸಂಗ್ರಹಣೆ ಸಂದರ್ಭವನ್ನು ರಚಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಇದು ಪ್ರೊಪ್ ಡ್ರಿಲ್ಲಿಂಗ್ ಇಲ್ಲದೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ "ವಿನಂತಿ-ಸ್ಥಳೀಯ" ಸಂಗ್ರಹಣೆಯನ್ನು ರಚಿಸುತ್ತದೆ.

ಪ್ರಮುಖ ಪರಿಕಲ್ಪನೆಗಳು ಮತ್ತು ವಿಧಾನಗಳು

`AsyncLocalStorage` ಅನ್ನು ಬಳಸುವುದರಿಂದ ಕೆಲವು ಪ್ರಮುಖ ವಿಧಾನಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

• new AsyncLocalStorage(): ನೀವು ವರ್ಗದ ನಿದರ್ಶನವನ್ನು ರಚಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ. ಸಾಮಾನ್ಯವಾಗಿ, ನೀವು ನಿರ್ದಿಷ್ಟ ರೀತಿಯ ಸಂದರ್ಭಕ್ಕಾಗಿ (ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಾ HTTP ವಿನಂತಿಗಳಿಗೆ ಒಂದು) ಒಂದೇ ನಿದರ್ಶನವನ್ನು ರಚಿಸುತ್ತೀರಿ ಮತ್ತು ಅದನ್ನು ಹಂಚಿದ ಮಾಡ್ಯೂಲ್‌ನಿಂದ ರಫ್ತು ಮಾಡುತ್ತೀರಿ.
• .run(store, callback): ಇದು ಪ್ರವೇಶ ಬಿಂದುವಾಗಿದೆ. ಇದು ಎರಡು ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: `store` (ನೀವು ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡಲು ಬಯಸುವ ಡೇಟಾ) ಮತ್ತು `callback` ಕಾರ್ಯ. ಇದು ಕಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ತಕ್ಷಣವೇ ಚಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಕಾಲ್‌ಬ್ಯಾಕ್‌ನ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಸಂಪೂರ್ಣ ಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ಅಸಮಕಾಲಿಕ ಅವಧಿಗೆ, ಒದಗಿಸಿದ `store` ಲಭ್ಯವಿರುತ್ತದೆ.
• .getStore(): ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯುವುದು ಹೀಗೆ. `.run()` ನಿಂದ ಪ್ರಾರಂಭಿಸಲಾದ ಅಸಮಕಾಲಿಕ ಹರಿವಿನ ಭಾಗವಾಗಿರುವ ಕಾರ್ಯದೊಳಗಿಂದ ಕರೆದಾಗ, ಅದು ಆ ಸಂದರ್ಭದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ `store` ವಸ್ತುವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಅಂತಹ ಸಂದರ್ಭದ ಹೊರಗೆ ಕರೆದರೆ, ಅದು `undefined` ಅನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.

`AsyncLocalStorage` ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಮ್ಮ ಹಿಂದಿನ ಉದಾಹರಣೆಯನ್ನು ಮರುಸಂರಚಿಸೋಣ.

            
const { AsyncLocalStorage } = require('async_hooks');

// 1. Create a single, shared instance
const asyncLocalStorage = new AsyncLocalStorage();

// 2. Our functions no longer need a 'context' parameter
function getUserFromDB(userId) {
  const store = asyncLocalStorage.getStore();
  console.log(`[${store.requestID}] Fetching user ${userId}`);
  return new Promise(resolve => setTimeout(() => resolve({ id: userId, name: 'Jane Doe' }), 100));
}

async function getPermissions(user) {
  const store = asyncLocalStorage.getStore();
  console.log(`[${store.requestID}] Getting permissions for ${user.name}`);
  await new Promise(resolve => setTimeout(resolve, 150));
  console.log(`[${store.requestID}] Permissions retrieved`);
  return { canEdit: true };
}

async function businessLogic() {
  const store = asyncLocalStorage.getStore();
  console.log(`[${store.requestID}] Starting request processing`);
  const user = await getUserFromDB(123);
  const permissions = await getPermissions(user);
  console.log(`[${store.requestID}] Request finished successfully`);
}

// 3. The main request handler uses .run() to establish the context
function handleRequest(requestID) {
  const context = { requestID };
  asyncLocalStorage.run(context, () => {
    // Everything called from here, sync or async, has access to the context
    businessLogic();
  });
}

console.log("Simulating concurrent requests with AsyncLocalStorage...");
handleRequest('req-A');
handleRequest('req-B');

            

              
                Copy
              
            
          

ಔಟ್ಪುಟ್ ಈಗ ಸಂಪೂರ್ಣವಾಗಿ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಪ್ರತ್ಯೇಕವಾಗಿದೆ:

            
Simulating concurrent requests with AsyncLocalStorage...
[req-A] Starting request processing
[req-A] Fetching user 123
[req-B] Starting request processing
[req-B] Fetching user 123
[req-A] Getting permissions for Jane Doe
[req-B] Getting permissions for Jane Doe
[req-A] Permissions retrieved
[req-A] Request finished successfully
[req-B] Permissions retrieved
[req-B] Request finished successfully

            

              
                Copy
              
            
          

ಶುದ್ಧ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಗಮನಿಸಿ. `getUserFromDB` ಮತ್ತು `getPermissions` ಕಾರ್ಯಗಳು ಶುದ್ಧವಾಗಿವೆ; ಅವು `context` ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ. ಅವು `getStore()` ಮೂಲಕ ಅಗತ್ಯವಿದ್ದಾಗ ಸಂದರ್ಭವನ್ನು ಸರಳವಾಗಿ ವಿನಂತಿಸಬಹುದು. ವಿನಂತಿಯ ಪ್ರವೇಶ ಬಿಂದುವಿನಲ್ಲಿ (`handleRequest`) ಒಮ್ಮೆ ಸಂದರ್ಭವನ್ನು ಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಅಸಮಕಾಲಿಕ ಸರಣಿಯ ಮೂಲಕ ಅಸ್ಪಷ್ಟವಾಗಿ ಸಾಗಿಸಲಾಗುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನ: Express.js ನೊಂದಿಗೆ ನೈಜ-ಪ್ರಪಂಚದ ಉದಾಹರಣೆ

`AsyncLocalStorage` ಗಾಗಿ ಅತ್ಯಂತ ಶಕ್ತಿಶಾಲಿ ಬಳಕೆಯ ಸಂದರ್ಭಗಳಲ್ಲಿ ಒಂದೆಂದರೆ Express.js ನಂತಹ ವೆಬ್ ಸರ್ವರ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ವಿನಂತಿ-ವ್ಯಾಪ್ತಿಯ ಸಂದರ್ಭವನ್ನು ನಿರ್ವಹಿಸುವುದು. ಒಂದು ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಯನ್ನು ನಿರ್ಮಿಸೋಣ.

ಸನ್ನಿವೇಶ

ನಮ್ಮಲ್ಲಿ ಒಂದು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಇದೆ, ಅದು ಹೀಗೆ ಮಾಡಬೇಕಾಗಿದೆ:

1. ಗುರುತಿಸುವಿಕೆಗಾಗಿ ಪ್ರತಿ ಒಳಬರುವ ವಿನಂತಿಗೆ ಅನನ್ಯ `requestID` ಅನ್ನು ನಿಯೋಜಿಸುವುದು.
2. ಕೈಯಾರೆ ರವಾನಿಸದೆಯೇ ಪ್ರತಿ ಲಾಗ್ ಸಂದೇಶದಲ್ಲಿ ಈ `requestID` ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸೇರಿಸುವ ಕೇಂದ್ರೀಕೃತ ಲಾಗಿಂಗ್ ಸೇವೆಯನ್ನು ಹೊಂದಿರುವುದು.
3. ದೃಢೀಕರಣದ ನಂತರ ಕೆಳಮಟ್ಟದ ಸೇವೆಗಳಿಗೆ ಬಳಕೆದಾರರ ಮಾಹಿತಿಯನ್ನು ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುವುದು.

ಹಂತ 1: ಕೇಂದ್ರ ಸಂದರ್ಭ ಸೇವೆಯನ್ನು ರಚಿಸಿ

`AsyncLocalStorage` ನಿದರ್ಶನವನ್ನು ನಿರ್ವಹಿಸುವ ಒಂದೇ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ರಚಿಸುವುದು ಉತ್ತಮ ಅಭ್ಯಾಸವಾಗಿದೆ.

ಫೈಲ್: `context.js`

            
const { AsyncLocalStorage } = require('async_hooks');

// This instance is shared across the entire application
const requestContext = new AsyncLocalStorage();

module.exports = { requestContext };

            

              
                Copy
              
            
          

ಹಂತ 2: ಸಂದರ್ಭವನ್ನು ಸ್ಥಾಪಿಸಲು ಮಿಡಲ್‌ವೇರ್ ಅನ್ನು ರಚಿಸಿ

Express ನಲ್ಲಿ, `run()` ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪೂರ್ಣ ವಿನಂತಿ ಜೀವಿತಾವಧಿಯನ್ನು ಸುತ್ತುವರಿಯಲು ಮಿಡಲ್‌ವೇರ್ ಸೂಕ್ತ ಸ್ಥಳವಾಗಿದೆ.

ಫೈಲ್: `app.js` (ಅಥವಾ ನಿಮ್ಮ ಮುಖ್ಯ ಸರ್ವರ್ ಫೈಲ್)

            
const express = require('express');
const { v4: uuidv4 } = require('uuid');
const { requestContext } = require('./context');
const logger = require('./logger');
const userService = require('./userService');

const app = express();

// Middleware to establish the async context for each request
app.use((req, res, next) => {
  const store = {
    requestID: uuidv4(),
    user: null // Will be populated after authentication
  };

  // .run() wraps the rest of the request handling (next())
  requestContext.run(store, () => {
    logger.info(`Request started: ${req.method} ${req.url}`);
    next();
  });
});

// A simulated authentication middleware
app.use((req, res, next) => {
  // In a real app, you'd verify a token here
  const store = requestContext.getStore();
  if (store) {
    store.user = { id: 'user-123', name: 'Alice' };
  }
  next();
});

// Your application routes
app.get('/user', async (req, res) => {
  logger.info('Handling /user request');
  try {
    const userProfile = await userService.getProfile();
    res.json(userProfile);
  } catch (error) {
    logger.error('Failed to get user profile', { error: error.message });
    res.status(500).send('Internal Server Error');
  }
});

const PORT = 3000;
app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

            

              
                Copy
              
            
          

ಹಂತ 3: ಸಂದರ್ಭವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬಳಸುವ ಲಾಗರ್

ಇಲ್ಲಿ ಮಾಂತ್ರಿಕತೆ ನಡೆಯುತ್ತದೆ. ನಮ್ಮ ಲಾಗರ್ ಎಕ್ಸ್‌ಪ್ರೆಸ್, ವಿನಂತಿಗಳು ಅಥವಾ ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಅರಿವಿಲ್ಲದೆ ಇರಬಹುದು. ಅದು ನಮ್ಮ ಕೇಂದ್ರ ಸಂದರ್ಭ ಸೇವೆಯ ಬಗ್ಗೆ ಮಾತ್ರ ತಿಳಿದಿದೆ.

ಫೈಲ್: `logger.js`

            
const { requestContext } = require('./context');

function log(level, message, details = {}) {
  const store = requestContext.getStore();
  const requestID = store ? store.requestID : 'N/A';

  const logObject = {
    timestamp: new Date().toISOString(),
    level: level.toUpperCase(),
    requestID,
    message,
    ...details
  };

  console.log(JSON.stringify(logObject));
}

const logger = {
  info: (message, details) => log('info', message, details),
  error: (message, details) => log('error', message, details),
  warn: (message, details) => log('warn', message, details),
};

module.exports = logger;

            

              
                Copy
              
            
          

ಹಂತ 4: ಸಂದರ್ಭವನ್ನು ಪ್ರವೇಶಿಸುವ ಆಳವಾಗಿ ನೆಸ್ಟೆಡ್ ಸೇವೆ

ನಮ್ಮ `userService` ಈಗ ಯಾವುದೇ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ನಿಯಂತ್ರಕದಿಂದ ಕೆಳಗೆ ರವಾನಿಸದೆಯೇ ವಿನಂತಿ-ನಿರ್ದಿಷ್ಟ ಮಾಹಿತಿಯನ್ನು ವಿಶ್ವಾಸದಿಂದ ಪ್ರವೇಶಿಸಬಹುದು.

ಫೈಲ್: `userService.js`

            
const { requestContext } = require('./context');
const logger = require('./logger');

// A simulated database call
async function fetchUserDetailsFromDB(userId) {
  logger.info(`Fetching details for user ${userId} from database.`);
  await new Promise(resolve => setTimeout(resolve, 50));
  return { company: 'Global Tech Inc.', country: 'Worldwide' };
}

async function getProfile() {
  const store = requestContext.getStore();
  if (!store || !store.user) {
    throw new Error('User not authenticated');
  }

  logger.info(`Building profile for user: ${store.user.name}`);

  // Even deeper async calls will maintain context
  const details = await fetchUserDetailsFromDB(store.user.id);

  return {
    id: store.user.id,
    name: store.user.name,
    ...details
  };
}

module.exports = { getProfile };

            

              
                Copy
              
            
          

ನೀವು ಈ ಸರ್ವರ್ ಅನ್ನು ಚಲಾಯಿಸಿ ಮತ್ತು `http://localhost:3000/user` ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡಿದಾಗ, ನಿಮ್ಮ ಕನ್ಸೋಲ್ ಲಾಗ್‌ಗಳು ಒಂದೇ `requestID` ಆರಂಭಿಕ ಮಿಡಲ್‌ವೇರ್‌ನಿಂದ ಆಳವಾದ ಡೇಟಾಬೇಸ್ ಕಾರ್ಯದವರೆಗಿನ ಪ್ರತಿ ಲಾಗ್ ಸಂದೇಶದಲ್ಲಿ ಇರುವುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸುತ್ತವೆ, ಇದು ಪರಿಪೂರ್ಣ ಸಂದರ್ಭ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ.

ಥ್ರೆಡ್ ಸುರಕ್ಷತೆ ಮತ್ತು ಸಂದರ್ಭ ಪ್ರತ್ಯೇಕತೆ ವಿವರಿಸಲಾಗಿದೆ

ಈಗ ನಾವು "ಥ್ರೆಡ್ ಸುರಕ್ಷತೆ" ಎಂಬ ಪದಕ್ಕೆ ಹಿಂತಿರುಗಬಹುದು. Node.js ನಲ್ಲಿ, ಚಿಂತೆಯು ನಿಜವಾದ ಸಮಾನಾಂತರ ರೀತಿಯಲ್ಲಿ ಒಂದೇ ಮೆಮೊರಿಯನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಪ್ರವೇಶಿಸುವ ಬಹು ಥ್ರೆಡ್‌ಗಳ ಬಗ್ಗೆ ಅಲ್ಲ. ಬದಲಿಗೆ, ಇದು ಈವೆಂಟ್ ಲೂಪ್ ಮೂಲಕ ಒಂದೇ ಮುಖ್ಯ ಥ್ರೆಡ್‌ನಲ್ಲಿ ತಮ್ಮ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಪರಸ್ಪರ ಬೆರೆಸುವ ಬಹು ಏಕಕಾಲಿಕ ಕಾರ್ಯಾಚರಣೆಗಳ (ವಿನಂತಿಗಳು) ಬಗ್ಗೆ. "ಸುರಕ್ಷತೆ" ಸಮಸ್ಯೆಯು ಒಂದು ಕಾರ್ಯಾಚರಣೆಯ ಸಂದರ್ಭವು ಇನ್ನೊಂದಕ್ಕೆ ಸೋರಿಕೆಯಾಗುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುವುದು.

`AsyncLocalStorage` ಅಸಮಕಾಲಿಕ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಸಂದರ್ಭವನ್ನು ಲಿಂಕ್ ಮಾಡುವ ಮೂಲಕ ಇದನ್ನು ಸಾಧಿಸುತ್ತದೆ.

ಇಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಸರಳೀಕೃತ ಮಾನಸಿಕ ಮಾದರಿ ಇದೆ:

1. `asyncLocalStorage.run(store, ...)` ಅನ್ನು ಕರೆದಾಗ, Node.js ಆಂತರಿಕವಾಗಿ ಹೀಗೆ ಹೇಳುತ್ತದೆ: "ನಾನು ಈಗ ವಿಶೇಷ ಸಂದರ್ಭವನ್ನು ಪ್ರವೇಶಿಸುತ್ತಿದ್ದೇನೆ. ಈ ಸಂದರ್ಭದ ಡೇಟಾ `store` ಆಗಿದೆ." ಇದು ಈ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಂದರ್ಭಕ್ಕೆ ಅನನ್ಯ ಆಂತರಿಕ ID ಯನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ.
2. ಈ ಸಂದರ್ಭವು ಸಕ್ರಿಯವಾಗಿರುವಾಗ ನಿಗದಿಪಡಿಸಲಾದ ಯಾವುದೇ ಅಸಮಕಾಲಿಕ ಕಾರ್ಯಾಚರಣೆಯು (ಉದಾಹರಣೆಗೆ, `new Promise`, `setTimeout`, `fs.readFile`) ಈ ಅನನ್ಯ ಸಂದರ್ಭ ID ಯೊಂದಿಗೆ ಟ್ಯಾಗ್ ಆಗುತ್ತದೆ.
3. ನಂತರ, ಈವೆಂಟ್ ಲೂಪ್ ಈ ಟ್ಯಾಗ್ ಮಾಡಲಾದ ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಕಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಾಗ, Node.js ಟ್ಯಾಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅದು ಹೀಗೆ ಹೇಳುತ್ತದೆ, "ಆಹ್, ಈ ಕಾಲ್‌ಬ್ಯಾಕ್ ಸಂದರ್ಭ ID X ಗೆ ಸೇರಿದೆ. ಕಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು ನಾನು ಈಗ ಆ ಸಂದರ್ಭವನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತೇನೆ."
4. ಈ ಮರುಸ್ಥಾಪನೆಯು ಕಾಲ್‌ಬ್ಯಾಕ್‌ನೊಳಗೆ `getStore()` ಗೆ ಸರಿಯಾದ `store` ಅನ್ನು ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ.
5. ಇನ್ನೊಂದು ವಿನಂತಿಯು ಬಂದಾಗ, `.run()` ಗೆ ಅದರ ಕರೆಯು ವಿಭಿನ್ನ ಆಂತರಿಕ ID ಯೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಸ ಸಂದರ್ಭವನ್ನು ರಚಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಅಸಿಂಕ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಈ ಹೊಸ ID ಯೊಂದಿಗೆ ಟ್ಯಾಗ್ ಆಗುತ್ತವೆ, ಇದು ಶೂನ್ಯ ಅತಿಕ್ರಮಣವನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ಈ ದೃಢವಾದ, ಕಡಿಮೆ-ಮಟ್ಟದ ಯಾಂತ್ರಿಕತೆಯು ಈವೆಂಟ್ ಲೂಪ್ ವಿವಿಧ ವಿನಂತಿಗಳಿಂದ ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಹೇಗೆ ಬೆರೆಸಿದರೂ, `getStore()` ಯಾವಾಗಲೂ ಆ ಕಾಲ್‌ಬ್ಯಾಕ್‌ನ ಅಸಿಂಕ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮೂಲತಃ ನಿಗದಿಪಡಿಸಿದ ಸಂದರ್ಭಕ್ಕಾಗಿ ಡೇಟಾವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರಿಗಣನೆಗಳು ಮತ್ತು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು

`AsyncLocalStorage` ಹೆಚ್ಚು ಆಪ್ಟಿಮೈಸ್ ಆಗಿದ್ದರೂ, ಅದು ಉಚಿತವಲ್ಲ. ಆಧಾರವಾಗಿರುವ `async_hooks` ಪ್ರತಿ ಅಸಮಕಾಲಿಕ ಸಂಪನ್ಮೂಲದ ರಚನೆ ಮತ್ತು ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಗೆ ಸ್ವಲ್ಪ ಓವರ್ಹೆಡ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ, ವಿಶೇಷವಾಗಿ I/O-ಬೌಂಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ, ಕೋಡ್ ಸ್ಪಷ್ಟತೆ, ನಿರ್ವಹಣೆ ಮತ್ತು ಅವಲೋಕನೀಯತೆಯ ಪ್ರಯೋಜನಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಈ ಓವರ್ಹೆಡ್ ನಗಣ್ಯವಾಗಿದೆ.

• ಒಮ್ಮೆ ನಿದರ್ಶನಗೊಳಿಸಿ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ ನಿಮ್ಮ `AsyncLocalStorage` ನಿದರ್ಶನಗಳನ್ನು ರಚಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ಮರುಬಳಸಿ. ಪ್ರತಿ ವಿನಂತಿಗೆ ಹೊಸ ನಿದರ್ಶನಗಳನ್ನು ರಚಿಸಬೇಡಿ.
• ಸ್ಟೋರ್ ಅನ್ನು ತೆಳ್ಳಗೆ ಇರಿಸಿ: ಸಂದರ್ಭದ ಸ್ಟೋರ್ ಕ್ಯಾಶ್ ಅಲ್ಲ. ID ಗಳು, ಟೋಕನ್‌ಗಳು ಅಥವಾ ಲಘು ಬಳಕೆದಾರರ ವಸ್ತುಗಳಂತಹ ಸಣ್ಣ, ಅಗತ್ಯ ಡೇಟಾ ತುಣುಕುಗಳಿಗಾಗಿ ಇದನ್ನು ಬಳಸಿ. ದೊಡ್ಡ ಪೇಲೋಡ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ.
• ಸ್ಪಷ್ಟ ಪ್ರವೇಶ ಬಿಂದುಗಳಲ್ಲಿ ಸಂದರ್ಭವನ್ನು ಸ್ಥಾಪಿಸಿ: `.run()` ಅನ್ನು ಕರೆಯಲು ಉತ್ತಮ ಸ್ಥಳಗಳು ಸ್ವತಂತ್ರ ಅಸಮಕಾಲಿಕ ಹರಿವಿನ ನಿರ್ಣಾಯಕ ಪ್ರಾರಂಭದಲ್ಲಿವೆ. ಇದು ಸರ್ವರ್ ವಿನಂತಿ ಮಿಡಲ್‌ವೇರ್, ಸಂದೇಶ ಕ್ಯೂ ಗ್ರಾಹಕರು ಅಥವಾ ಕೆಲಸದ ಶೆಡ್ಯೂಲರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.
• ಫೈರ್-ಅಂಡ್-ಫಾರ್ಗೆಟ್ ಕಾರ್ಯಾಚರಣೆಗಳ ಬಗ್ಗೆ ಜಾಗರೂಕರಾಗಿರಿ: ನೀವು `run` ಸಂದರ್ಭದಲ್ಲಿ ಅಸಿಂಕ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದರೆ ಆದರೆ ಅದನ್ನು `await` ಮಾಡದಿದ್ದರೆ (ಉದಾಹರಣೆಗೆ, `doSomething().catch(...)`), ಅದು ಇನ್ನೂ ಸಂದರ್ಭವನ್ನು ಸರಿಯಾಗಿ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತದೆ. ಇದು ತಮ್ಮ ಮೂಲಕ್ಕೆ ಹಿಂದಿರುಗಿಸಬೇಕಾದ ಹಿನ್ನೆಲೆ ಕಾರ್ಯಗಳಿಗೆ ಶಕ್ತಿಶಾಲಿ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ.
• ನೆಸ್ಟಿಂಗ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ: ನೀವು `.run()` ಗೆ ಕರೆಗಳನ್ನು ನೆಸ್ಟ್ ಮಾಡಬಹುದು. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂದರ್ಭದೊಳಗಿಂದ `.run()` ಅನ್ನು ಕರೆದರೆ ಹೊಸ, ನೆಸ್ಟೆಡ್ ಸಂದರ್ಭವನ್ನು ರಚಿಸುತ್ತದೆ. `getStore()` ನಂತರ ಆಂತರಿಕ ಸ್ಟೋರ್ ಅನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಇದು ನಿರ್ದಿಷ್ಟ ಉಪ-ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ಸಂದರ್ಭವನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಅತಿಕ್ರಮಿಸಲು ಅಥವಾ ಸೇರಿಸಲು ಉಪಯುಕ್ತವಾಗಬಹುದು.

Node.js ಗಿಂತಲೂ ಮೀರಿ: `AsyncContext` ನೊಂದಿಗೆ ಭವಿಷ್ಯ

ಅಸಮಕಾಲಿಕ ಸಂದರ್ಭ ನಿರ್ವಹಣೆಯ ಅಗತ್ಯವು Node.js ಗೆ ಮಾತ್ರ ಸೀಮಿತವಲ್ಲ. ಸಂಪೂರ್ಣ JavaScript ಪರಿಸರ ವ್ಯವಸ್ಥೆಗೆ ಅದರ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಗುರುತಿಸಿ, `AsyncContext` ಎಂಬ ಔಪಚಾರಿಕ ಪ್ರಸ್ತಾವನೆಯು JavaScript (ECMAScript) ಅನ್ನು ಪ್ರಮಾಣೀಕರಿಸುವ TC39 ಸಮಿತಿಯ ಮೂಲಕ ಸಾಗುತ್ತಿದೆ.

`AsyncContext` ಪ್ರಸ್ತಾವನೆಯು Node.js ನ `AsyncLocalStorage` ನಿಂದ ಹೆಚ್ಚು ಪ್ರೇರಿತವಾಗಿದೆ ಮತ್ತು ವೆಬ್ ಬ್ರೌಸರ್‌ಗಳು ಸೇರಿದಂತೆ ಎಲ್ಲಾ ಆಧುನಿಕ JavaScript ಪರಿಸರಗಳಲ್ಲಿ ಲಭ್ಯವಿರುವ ಬಹುತೇಕ ಒಂದೇ ರೀತಿಯ API ಅನ್ನು ಒದಗಿಸುವ ಗುರಿಯನ್ನು ಹೊಂದಿದೆ. ಇದು ಮುಂಭಾಗದ ಅಭಿವೃದ್ಧಿಗೆ ಶಕ್ತಿಶಾಲಿ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅನ್‌ಲಾಕ್ ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ ಏಕಕಾಲಿಕ ರೆಂಡರಿಂಗ್ ಸಮಯದಲ್ಲಿ React ನಂತಹ ಸಂಕೀರ್ಣ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಸಂದರ್ಭವನ್ನು ನಿರ್ವಹಿಸುವುದು ಅಥವಾ ಸಂಕೀರ್ಣ ಘಟಕ ಮರಗಳಾದ್ಯಂತ ಬಳಕೆದಾರರ ಸಂವಹನ ಹರಿವುಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು.

ತೀರ್ಮಾನ: ಘೋಷಣಾತ್ಮಕ ಮತ್ತು ದೃಢವಾದ ಅಸಮಕಾಲಿಕ ಕೋಡ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು

ಅಸಮಕಾಲಿಕ ಕಾರ್ಯಾಚರಣೆಗಳಾದ್ಯಂತ ಸ್ಥಿತಿಯನ್ನು ನಿರ್ವಹಿಸುವುದು ಒಂದು ಮೋಸದಿಂದ ಸಂಕೀರ್ಣವಾದ ಸಮಸ್ಯೆಯಾಗಿದ್ದು, ಇದು ವರ್ಷಗಳಿಂದ JavaScript ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸವಾಲು ಹಾಕಿದೆ. ಕೈಪಿಡಿ ಪ್ರೊಪ್ ಡ್ರಿಲ್ಲಿಂಗ್ ಮತ್ತು ದುರ್ಬಲ ಸಮುದಾಯ ಗ್ರಂಥಾಲಯಗಳಿಂದ `AsyncLocalStorage` ರೂಪದಲ್ಲಿ ಪ್ರಮುಖ, ಸ್ಥಿರ API ಗೆ ಪ್ರಯಾಣವು Node.js ವೇದಿಕೆಯ ಗಮನಾರ್ಹ ಪ್ರಬುದ್ಧತೆಯನ್ನು ಗುರುತಿಸುತ್ತದೆ.

ಸುರಕ್ಷಿತ, ಪ್ರತ್ಯೇಕ ಮತ್ತು ಅಸ್ಪಷ್ಟವಾಗಿ ಪ್ರಚಾರಗೊಂಡ ಸಂದರ್ಭಕ್ಕಾಗಿ ಒಂದು ಯಾಂತ್ರಿಕತೆಯನ್ನು ಒದಗಿಸುವ ಮೂಲಕ, `AsyncLocalStorage` ನಮಗೆ ಶುದ್ಧ, ಹೆಚ್ಚು ಡಿಕಪಲ್ಡ್ ಮತ್ತು ಹೆಚ್ಚು ನಿರ್ವಹಿಸಬಹುದಾದ ಕೋಡ್ ಅನ್ನು ಬರೆಯಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಟ್ರೇಸಿಂಗ್, ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಲಾಗಿಂಗ್ ನಂತರದ ಆಲೋಚನೆಗಳಾಗಿರದ ಆದರೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ರಚನೆಯಲ್ಲಿ ಹೆಣೆದುಕೊಂಡಿರುವ ಆಧುನಿಕ, ಅವಲೋಕನೀಯ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಇದು ಒಂದು ಮೂಲಾಧಾರವಾಗಿದೆ.

ನೀವು ಏಕಕಾಲಿಕ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಯಾವುದೇ ಅಲ್ಪವಲ್ಲದ Node.js ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, `AsyncLocalStorage` ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ಕೇವಲ ಉತ್ತಮ ಅಭ್ಯಾಸವಲ್ಲ—ಇದು ಅಸಮಕಾಲಿಕ ಜಗತ್ತಿನಲ್ಲಿ ದೃಢತೆ ಮತ್ತು ಸ್ಕೇಲೆಬಿಲಿಟಿಯನ್ನು ಸಾಧಿಸಲು ಒಂದು ಮೂಲಭೂತ ತಂತ್ರವಾಗಿದೆ.